What are sticky sessions? How is it implemented?
Sticky sessions (session affinity) is a mechanism that binds a user's session to a specific target, ensuring all requests from that user during the session are routed to the same target. It is implemented using HTTP cookies [citation:1][citation:3].
Sticky sessions, also known as session affinity, is a mechanism that allows the load balancer to bind a user's session to a specific target. This ensures that all requests from the user during that session are sent to the same backend server, which is critical for applications that store session state locally. It is implemented using HTTP cookies [citation:1][citation:3].
There are two types of cookies used by the Application Load Balancer (ALB): duration-based cookies generated by the ALB (cookie name AWSALB) and application-based cookies generated by the target (the target defines the cookie name) [citation:3]. The Network Load Balancer (NLB) supports source IP address-based stickiness [citation:1].
Scenario Questions
- 1
We have a simple web app behind an Application Load Balancer on EC2. How would you enable sticky sessions so that a user's requests keep hitting the same instance?
- 2
If you forget to configure sticky sessions and a user logs in, what problem might they see when they navigate to another page?
- 1
Your team notices that after deploying a new version, some users are getting stuck on old data because of sticky sessions. How would you troubleshoot and resolve this?
- 2
Explain the trade‑offs between using the ELB‑generated cookie versus an application‑generated cookie for session affinity.
- 3
During a load test you see uneven traffic distribution despite sticky sessions being enabled. What could be causing it and how would you fix it?
- 1
Design a scalable architecture for a stateful web service on EC2 that requires session affinity, considering failover, scaling, and cost. Which sticky session mechanism would you choose and why?
- 2
How would you modify the sticky session configuration to handle a scenario where a user’s session needs to survive an instance failure?
- 1
Our organization wants to migrate from ELB sticky sessions to a fully stateless design using a distributed session store. What are the architectural implications, migration steps, and how would you ensure zero downtime?
- 2
When multiple teams share a common ALB, how would you enforce isolation of sticky session configurations while maintaining centralized management?
Follow-up Questions
- ❓What happens if the instance handling a sticky session crashes?
- ❓How does the TTL of the sticky cookie affect user experience?
- ❓Can you combine sticky sessions with auto‑scaling, and what are the pitfalls?